Shape Up: Stop Running in Circles and Ship Work that Matters

https://gyazo.com/039dbcb829972eb6f551d3e9e23fe303

Basecamp がプロダクト開発をしているときにどうやってるかを紹介してる本

基本的にはBasecampは 6 week cycle (タイムボックス的な) でプロダクトを開発していて、その中で価値の高いものを品質よく作っていくためのいろいろ

Shaping

プロジェクトを実際にスケジューリングする前に行うフェーズ

Shapingをするときには、具体的すぎず、曖昧すぎずほどよいレベルのものを成果物としないといけない。

具体的すぎると、エンジニア や デザイナー が専門スキルを活かす余地が減ってしまい、局所最適な解しか選べなくなる

曖昧すぎると、要件の内容がわからなかったり、何を作るか、どんな価値を提供したいのかという意思疎通が難しくなる

重要な要素

It's rough

デザイナーや開発者は、専門性を活かす余地が必要

詳細化をしすぎると、局所最適解しか選べずROIの悪化につながる

It's solved

具体的なタスクなどについては言及しない rough ではありながら、何を解決するべきかということは明確になっていないといけない。

プロジェクトのリスク現象のために、すぐに思いつくような質問や落とし穴は全て解決されていなくてはいけない

It's bounded

何をしないかということも決まっている

これはチームに対してどこで止まるかというこを示す

チームには当然リソースの制約があるわけなのでスコープを明確に絞る必要がある

誰が Shaping をするか

技術的な可否やビジネスの優先度どちらも理解している必要がある

これらのスキルを1人で持つか、複数人で共同作業するかが必要

Basecampでは、Shaping中のものと開発中のもので２つのレーンを用意してる

Steps to shaping

Set boundaries

Rough out the elements

Address risks and rabbit holes

Write the pitch

Two Tracks

Basecamp では、 Two Tracks を利用してる

あるチームが Shaping を行い、あるチームが開発とデザインを作ったりを行う

Bread Boarding

UIを必要以上に詳細化してしまうとデザイナーにバイアスを与えてしまいクリエイティブを発揮できない

とはいえ、何も絵などがない状態だとラフすぎる

したがって以下の要素のみを最低限のUI制約のみを定義する

Places

どこに置くか (どの画面におくか)

Affordances

ユーザーが取れるアクション

e.g タップ、トグル、フィールド

Connection lines

Affordance の結果ユーザーの画面推移などがどう変化するか

https://gyazo.com/fb72ebf0b86d5203652d1a7ae3ef6655

Write the Pitch

ここまでタスクが Shaped になると、今度は Betting Table (案件をやるやらないを決める会) に持っていくために Pitch に改めてまとめる

以下の要素を含むべきとしている

Problem

どんな問題か、誰が何ができないかなど

Appetite

この問題を解くのにどれくらいの時間やリソースを割きたいか

Solution

Bread Boarding の内容などをさらに説明のために補足したもの

Rabbit Holes

Solutionのうち後に判断が必要になるような制約や障害になり得る情報

No-gos

今回のスコープの中には明確に入れないもの

Betting

BasecampではBacklogでタスクを管理するようなことはしていない

6週間ごとに 2週間の Betting Table の機会をもうけている

この会に漏れたものについては、次に持ち越されることはなく次の Betting Table に新規に持ち込まれることになる

したがって常に6週間分のゴールしか存在しない

Team and Project sizes

1つのプロジェクトは1人のデザイナーと1,2人のプログラマによって構成される

What about bugs

まずはそもそもそのバグには今このタイミングである任意のリソースをかけて修正する価値があるかを考える

Use cool-down

6週間ごとに2週間の Betting Table を設けるので開発チームは手が空くためこの時間を使ってリファクタリングなどを行ったりする

Bring it to the betting table

Schedule a bug bash

1年に1回程度、休みの近くのcycleを丸ごとbug fixにあてるときもある

Question to ask

Does the problem matter?

Is the appetite right?

Is the solution attractive?

Is this right time?

Are the right people available?

Building

Map the scope

プロジェクトごとにScope Mapを作ってる

https://gyazo.com/256502325a31d2de4315c97da277cbdf

https://gyazo.com/3d7eadb0d78ba77041e128fd48b505d9

こういう形でタスクではなくより抽象的な機能郡でスコープを切っていく

これらは、徐々に発見されていくものになる

Work is like hill

スコープに分割していったら、それらのスコープがどういう進捗かというの

https://gyazo.com/cccac3abfe695bb2d281d7c87dbd2e8b

https://gyazo.com/97bf984fab0c528509149612a128e6cc

進捗は、具体的な日付などではなく、山として表現する

不確実性を下げるというフェーズとあとはやるだけというフェーズに分かれると考えてる

QA for the edges

Basecampは今の規模でQAが1人しかいない

QAはエッジケースを見つけるのを責任にしており、基本的なUXやソフトウェアの品質は開発者やデザイナーがそれぞれ持つ形になっている

Therefore we think of QA as a level-up, not a gate or a check-point

いい言葉だ

感想

特にエンジニアとデザイナーがクリエイティブを発揮する必要があるから要件定義を荒すぎず、具体的すぎずというところがかなり参考になった

6週間サイクルでの開発はバックログって本当にそんなに長い必要あるんだっけ？ということを改めて考えさせてくれるものがあったのでこの辺は参考にしていきたい

基盤開発チーム的なところではこういうマインドでロードマップを作っていってもいいんじゃないかとか思った

deeetさんの発表でメルカリがこういうマインドセットでリリースサイクルを組んでるという話もあった

参考